Wirelessly updating field programmable gate arrays upon detection of hardware vulnerability

ABSTRACT

A mechanism for wirelessly updating an FPGA that is built into a wireless mobile or another wireless electronic device is described herein. The wireless update may be performed responsive to detecting a hardware vulnerability or another hardware issue in the mobile device. When the hardware vulnerability or another hardware issue is detected, the mechanism may identify a fix for the hardware vulnerability. A fix may be a particular FPGA configuration update known to fix the issue. The configuration update to the FPGA is received and the current FPGA configuration is overwritten with data from the configuration update. A determination is made that the hardware vulnerability no longer exists.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.16/941,393 filed on Jul. 28, 2020, which is hereby incorporated byreference in its entirety.

TECHNICAL FIELD

This disclosure generally relates to field programmable gate arrays(“FPGAs”), and more particularly to performing wireless configurationupdates to the FPGAs.

BACKGROUND

Various electronic devices are built with one or more FPGAs instead of aconventional processor or processors. FPGAs are generally semiconductordevices which contain programmable gates or blocks and interconnectioncircuits. FPGAs include hardware components that, unlike hardwarecomponents of regular processors, may be reprogrammed after manufacturefor different tasks. To program or reprogram an FPGA a HardwareDescription Language (“HDL”) definition or a schematic design may beused. Generally, the HDL definition or schematic design is uploaded tothe FPGA through a wired connection while the FPGA is in a configurationmode. Once the transfer is complete, the FPGA switches to user mode forperforming programmed functions. The update processes are generally donein a lab or in a controlled environment. Thus, it is very difficult toupdate the hardware configuration of the FPGA on consumer electronicdevices because these devices are no longer controlled by themanufacturer (e.g., they are in the hands of consumers) and havingconsumers ship devices back for reconfiguration is a very resourceintensive process.

SUMMARY

Therefore, this disclosure describes a mechanism for wirelessly updatingan FPGA that is built into a wireless mobile or another wirelesselectronic device even after the device has left the manufacturer. Thewireless update may be performed responsive to detecting a hardwarevulnerability or another hardware issue in the mobile device thatincludes an FPGA. When the hardware vulnerability or another hardwareissue is detected (e.g., by a software executed on the mobile device),the mechanism may identify a fix for the hardware vulnerability. Forexample, a fix may be a particular FPGA configuration update known tofix the issue. A request is transmitted to a server for the fix to thehardware vulnerability and configuration update to the FPGA is receivedfrom the server responsive to the request. The current FPGAconfiguration is then overwritten with data from the configurationupdate and a determination is made that the hardware vulnerability nolonger exists.

BRIEF DESCRIPTION OF DRAWINGS

The disclosed embodiments have other advantages and features which willbe more readily apparent from the detailed description, the appendedclaims, and the accompanying figures (or drawings). A brief introductionof the figures is below.

Figure (FIG.) 1 illustrates a system for wirelessly updating an FPGAthat is built into a wireless mobile or another wireless electronicdevice, in accordance with some embodiments of this disclosure.

FIG. 2 illustrates exemplary modules of a system for wirelessly updatingan FPGA, in accordance with some embodiments of this disclosure.

FIG. 3 is a block diagram illustrating components of an example machineable to read instructions from a machine-readable medium and executethem in a processor (or controller).

FIG. 4 illustrates a flow chart for wirelessly updating an FPGA, inaccordance with some embodiments of this disclosure.

FIG. 5 illustrates another flow chart for wirelessly updating an FPGA,in accordance with some embodiments of this disclosure.

DETAILED DESCRIPTION

The Figures and the following description relate to preferredembodiments by way of illustration only. It should be noted that fromthe following discussion, alternative embodiments of the structures andmethods disclosed herein will be readily recognized as viablealternatives that may be employed without departing from the principlesof what is claimed.

Reference will now be made in detail to several embodiments, examples ofwhich are illustrated in the accompanying figures. It is noted thatwherever practicable similar or like reference numbers may be used inthe figures and may indicate similar or like functionality. The figuresdepict embodiments of the disclosed system (or method) for purposes ofillustration only. One skilled in the art will readily recognize fromthe following description that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles described herein.

FIG. 1 illustrates a system (a wireless update system) for wirelesslyupdating an FPGA that is built into a wireless mobile or anotherwireless electronic device. Wireless update system 100 includes a mobiledevice 110 (with a wireless connection) and a server 130. Mobile device110 may be any electronic device with wireless connectivity, e.g., asmart phone, an electronic tablet, a portable computer, or anothersuitable device. Mobile device 110 includes a field programmable gatearray 115 and an updating system 120. FPGA 115 performs processingfunctions as any other processor may perform. Updating system 120 mayreceive an FPGA configuration update through a particular interface forreceiving an FPGA configuration update, process that update, and applythe update to FPGA 115. Mobile device 110 may communicate with server130 during the FPGA configuration update process.

Server 130 may be one or more servers configured to communicate withmobile devices (e.g., mobile device 110). Server 130 may includedatabase 135 that stores various FPGA configurations and/or FPGAconfiguration metadata for updating FPGA configurations on mobiledevices. In some embodiments, server 130 may include one or moresoftware applications configured to be executed on mobile devices fordetecting vulnerabilities or other issues that may be resolved byapplying an FPGA configuration update. Server 130 may store differentapplications for different types of mobile devices (e.g., for mobiledevices with different operating systems). That is, server 130 maydetermine a type associated with the mobile device (e.g., based on theoperating system of the mobile device) and select the appropriateapplication based on the type associated with the mobile device. Server130 may transmit an appropriate application to each mobile device, whichis executed on the mobile device to identify any hardwarevulnerabilities or other issues that may be fixed by applying an updateto the FPGA configuration of the device.

FIG. 2 illustrates exemplary modules of a system for wirelessly updatingan FPGA. The wireless update system may include, on mobile device 110,communications module 210, vulnerability detection module 220, andupdate module 230. The wireless update system may also includecommunications module 250, FPGA configuration update retrieval module260, and database engine 270 on server 130. The modules depicted in FIG.2 are merely exemplary; fewer or more modules may be included to executethe functions described with respect to the wireless update system.

Mobile device 110 includes communications module 210. Communicationsmodule 210 may include circuitry providing wireless connectivity to themobile device. Thus, communications module 210 may communicate withserver 130 via the wireless connection. The mobile device may receiveone or more applications via communications module 210 that may be usedfor detecting hardware vulnerabilities or other issues that may be fixedwith an appropriate configuration update to the FPGA. A security flawthat may be fixed with an FPGA update may be hardware vulnerability. Abattery issue (e.g., overheating/overusing the battery) caused by aparticular configuration of the FPGA may be a hardware vulnerability.Communications module 210 may include a software portion, a hardwareportion, or a combination of the two. In some embodiments,communications module may include network interface device 320 (FIG. 3).

Vulnerability detection module 220 detects a hardware vulnerability inthe mobile device. For example, vulnerability detection module 220 mayexecute an application (e.g., application wirelessly downloaded fromserver 130) on the mobile device to detect the hardware vulnerability.In some embodiments, vulnerability detection module 220 via theapplication may retrieve a plurality of state codes for a plurality ofhardware devices that are part of the mobile device. The state codes maybe generated by the hardware devices as the hardware devices performtheir tasks. In some embodiments, vulnerability detection module 220may, via the application and using application programming interfaces ofeach of the hardware devices, instruct each of the hardware devices togenerate a state code. For example, vulnerability detection module 220may instruct a hardware device (e.g., via a command) to execute a statecheck and output the resulting state code. In some embodiments, abattery system may return a specific code indicating that the batteryoverheats or is overused.

Vulnerability detection module 220 may compare each state code of theplurality of state codes with state codes in a list of state codes. Oneor more state code in the list of state codes may have a correspondinghardware vulnerability. For example, the mobile device may download alist of state codes and corresponding hardware vulnerabilities.Vulnerability detection module 220 may, via the application, retrievethe list from memory to perform the comparison. In some embodiments, thelist of state codes may be stored in a database (e.g., database 135 onserver 130). Vulnerability detection module 220 may transmit the codesto the server for comparison. In some embodiments, vulnerabilitydetection module 220 may retrieve the list of state codes from theserver to perform the comparison.

In some embodiments, the list of state codes may include a combinationof state codes that correspond to a hardware vulnerability. For example,to match a particular hardware vulnerability, a combination of devicesmay have to output specific state codes. That is, device one may outputa specific state code (e.g., a particular hexadecimal value) and devicetwo may output its own specific state code (e.g., another hexadecimalvalue). If both state codes match the statues codes in the list,vulnerability detection module 220 determines that the matching hardwarevulnerability has been detected. A state code may be any unique value,for example, a decimal number, a hexadecimal number, a string, oranother suitable state code.

In response to determining that at least one of the state codes matchesa state code in the list of state codes, vulnerability detection module220 detects the hardware vulnerability. For example, vulnerabilitydetection module 220 may store a hardware vulnerability identifier(e.g., a hexadecimal value) corresponding to the hardware vulnerability.A hardware vulnerability may be any hardware issue can be fixed byreconfiguring the FPGA. For example, a hardware vulnerability may bedetected when the FPGA is causing the mobile device to overheat due tothe gate or block configuration. Another example of a hardwarevulnerability may be inappropriate power usage (e.g., using too much ortoo little power). Using too much power may cause the mobile device tooverheat and/or run out of power quickly where it needs to recharge moreoften. Using too little power may cause the mobile device toinadequately perform when performance is needed.

In some embodiments, when performing detection, vulnerability detectionmodule 220 may receive, from server 130, executable code configured todetect the hardware vulnerability. That is, the application referredabove may be received prior to executing the process for wirelesslyupdating the FPGA or during the process for wirelessly updating theFPGA. In some embodiments, the executing code (e.g., applicationdescribed above) may be loaded onto the mobile device prior to needingthe update (e.g., when the device is manufactured) and executed duringthe process for wirelessly updating an FPGA by, for example, a built-infunction triggered from server 130. In some embodiments, the executablecode may be downloaded to the mobile device during the process forwirelessly updating an FPGA, for example, by vulnerability detectionmodule 220. Vulnerability detection module 220 then executes theexecutable code. The executable code, as discussed above, may readand/or cause the hardware devices within the mobile device to generatethe plurality of state codes and collect those state codes.

In response to detecting the hardware vulnerability on the mobiledevice, vulnerability detection module 220 identifies a configurationupdate to the FPGA that fixes the hardware vulnerability. For example,vulnerability detection module 220 may store a hardware vulnerabilityidentifier that matches the status code. Vulnerability detection module220 may retrieve the stored hardware vulnerability identifier andcompare the hardware vulnerability identifier with each hardwarevulnerability identifier in a list of hardware vulnerabilityidentifiers. Some of the hardware vulnerability identifiers in the listmay have a corresponding configuration update for the FPGA. That is, thecorresponding configuration update for the FPGA is known to fix thehardware vulnerability. In response to determining that the hardwarevulnerability identifier matches a hardware vulnerability identifier inthe list, vulnerability detection module 220 may store the matchinghardware vulnerability identifier. For example, vulnerability detectionmodule 220 may store a hexadecimal value as the hardware vulnerabilityidentifier.

Vulnerability detection module 220 may pass the hardware vulnerabilityidentifier to update module 230. Update module 230 may receive thehardware vulnerability identifier and transmit, to server 130, a requestfor the fix to the hardware vulnerability. The request may include anidentifier of the configuration update to the FPGA. In some embodiments,the identifier of the configuration update to the FPGA may be thehardware vulnerability identifier that was passed from the vulnerabilitydetection module. While in some embodiments, the identifier of theconfiguration update to the FPGA may be a different value. For example,the identifier of the configuration update to the FPGA may correspond toa hardware vulnerability identifier. Mobile device 110 and/or server 130may store a table that includes hardware vulnerability identifiers andcorresponding identifiers of the configuration update to the FPGA.

Update module 230 may perform the transmission through communicationsmodule 210. For example, update module 230 may pass the request tocommunications module 210 to be sent to server 130. Update module 230may receive, from server 130, the configuration update to the FPGA.Update module 230 may receive the configuration update throughcommunications module 210. That is, communications module 210 may passthe response, including the configuration update to the FPGA to updatemodule 230. Update module 230 may then overwrite a current FPGAconfiguration with data from the configuration update. After the updatecomplete and/or during the update process update module 230 may restartmobile device 110 one or more times.

When the update is complete, update module 230 may determine whether thehardware vulnerability no longer exists. For example, update module 230may re-execute the executable code described above which may retrieveone or more new state codes generated in response to re-execution of theexecutable code. Update module 230 may determine, based on the one ormore new state codes, whether the vulnerability no longer exists. Forexample, update module 230 may compare the retrieved state codes withstate codes in a list of state codes indicating that the fix wassuccessful. If a state code or a combination of state codes match astate code or a combination of state codes in the list, update module230 may determine that the hardware vulnerability no longer exists.

Server 130 may include communications module 250, FPGA Configurationupdate retrieval module 260, and a database engine 270. Communicationsmodule 250 may transmit and receive various data to and from mobiledevice 110. Communications module 250 may transmit, to the mobiledevice, executable code for detecting hardware vulnerabilities. Asdiscussed above, the executable code may be an application executed onthe mobile device. Communications module 250 may receive, from mobiledevice 110, a request for a fix to a detected hardware vulnerability.When communications module 250 receives the request, communicationsmodule 250 may pass the request to FPGA Configuration Update RetrievalModule 260.

FPGA configuration update retrieval module 260 may extract, from therequest, an identifier of a configuration update to the FPGA. FPGAconfiguration update retrieval module 260 may generate a database queryusing the extracted identifier for a configuration update to the FPGAand transmit the query to database engine 270. Database engine 270 maycause retrieval from a database (e.g., database 135) of variousconfiguration updates to the FPGA and corresponding identifiers. Thatis, database engine 270 may access a database table and retrieve aconfiguration update to the FPGA by submitting an identifier to thedatabase. Database engine 270 may store other information including, forexample, state codes and corresponding hardware vulnerability issues.

FPGA configuration update retrieval module 260 may receive, fromdatabase engine 270, a matching configuration update to the FPGA andpass the configuration update to communications module 250.Communications module 250 may transmit the configuration update to theFPGA to mobile device 110. In some embodiments, communications module250 may receive, from mobile device 110, a confirmation that thehardware vulnerability has been fixed. The confirmation may be storedusing database engine 270 in a database with a corresponding mobiledevice identifier to evidence that the corresponding mobile device hasbeen fixed.

Computing Machine Architecture

FIG. 3 is a block diagram illustrating components of an example machineable to read instructions from a machine-readable medium and executethem in a processor (or controller). Specifically, FIG. 3 shows adiagrammatic representation of a machine in the example form of acomputer system 300 within which program code (e.g., software) forcausing the machine to perform any one or more of the methodologiesdiscussed herein may be executed. The program code may be comprised ofinstructions 324 executable by one or more processors 302. Inalternative embodiments, the machine operates as a standalone device ormay be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server machineor a client machine in a server-client network environment, or as a peermachine in a peer-to-peer (or distributed) network environment.

The machine may be a server computer, a client computer, a personalcomputer (PC), a tablet PC, a set-top box (STB), a personal digitalassistant (PDA), a cellular telephone, a smartphone, a web appliance, anetwork router, switch or bridge, or any machine capable of executinginstructions 324 (sequential or otherwise) that specify actions to betaken by that machine. Further, while only a single machine isillustrated, the term “machine” shall also be taken to include anycollection of machines that individually or jointly execute instructions324 to perform any one or more of the methodologies discussed herein.

The example computer system 300 includes a processor 302 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU), adigital signal processor (DSP), one or more application specificintegrated circuits (ASICs), one or more radio-frequency integratedcircuits (RFICs), or any combination of these), a main memory 304, and astatic memory 306, which are configured to communicate with each othervia a bus 308. The computer system 300 may further include visualdisplay interface 310. The visual interface may include a softwaredriver that enables displaying user interfaces on a screen (or display).The visual interface may display user interfaces directly (e.g., on thescreen) or indirectly on a surface, window, or the like (e.g., via avisual projection unit). For ease of discussion the visual interface maybe described as a screen. The visual interface 310 may include or mayinterface with a touch enabled screen. The computer system 300 may alsoinclude alphanumeric input device 312 (e.g., a keyboard or touch screenkeyboard), a cursor control device 314 (e.g., a mouse, a trackball, ajoystick, a motion sensor, or other pointing instrument), a storage unit316, a signal generation device 318 (e.g., a speaker), and a networkinterface device 320, which also are configured to communicate via thebus 308.

The storage unit 316 includes a machine-readable medium 322 on which isstored instructions 324 (e.g., software) embodying any one or more ofthe methodologies or functions described herein. The instructions 324(e.g., software) may also reside, completely or at least partially,within the main memory 304 or within the processor 302 (e.g., within aprocessor's cache memory) during execution thereof by the computersystem 300, the main memory 304 and the processor 302 also constitutingmachine-readable media. The instructions 324 (e.g., software) may betransmitted or received over a network 326 via the network interfacedevice 320.

While machine-readable medium 322 is shown in an example embodiment tobe a single medium, the term “machine-readable medium” should be takento include a single medium or multiple media (e.g., a centralized ordistributed database, or associated caches and servers) able to storeinstructions (e.g., instructions 324). The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring instructions (e.g., instructions 324) for execution by themachine and that cause the machine to perform any one or more of themethodologies disclosed herein. The term “machine-readable medium”includes, but not be limited to, data repositories in the form ofsolid-state memories, optical media, and magnetic media.

FIG. 4 illustrates flow chart 400 for wirelessly updating an FPGA, inaccordance with some embodiments of this disclosure. The actions of FIG.4 are from the perspective of a mobile device (e.g. mobile device 110).Mobile device 110 may have one or more components of FIG. 3 . Forexample, mobile device 110 may include processor 302, main memory 304,network interface device 320, and/or other components. Processor 302 maybe the FPGA and mobile device 110 may include a second processor (notshown) for performing the FPGA update operation.

At 402, mobile device 110 detects a hardware vulnerability. Mobiledevice 110 may receive an application for detecting hardwarevulnerabilities using network interface 320 over network 326. Mobiledevice 110 may execute the application using processor 302. However, themobile device may have a second processor (not shown) for performingFPGA configuration updates. In some embodiments, the update process andthe application may be executed by the second processor. The mobiledevice may reboot in an upgrade mode which will instruct the mobiledevice to execute code using the second processor.

At 404, mobile device 110, in response to detecting the hardwarevulnerability in the mobile device, identifies a fix for the hardwarevulnerability. Mobile device 110 may make the identification byexecuting the downloaded application using processor 302 or the secondprocessor (not shown). At 406, mobile device 110 transmits, to a server(e.g., server 130), a request for the fix to the hardware vulnerability,the request including an identifier of the configuration update to theFPGA. For example, mobile device 110 may transmit the request to server130 using network interface device 320 via network 326.

At 408, mobile device 110 receives, from the server, the configurationupdate to the FPGA. For example, mobile device 110 may receive theconfiguration update via network 326 through network interface device320. The mobile device may store the received configuration update inmain memory 304 and/or storage unit 316. At 410, mobile device 110overwrites a current FPGA configuration with data from the configurationupdate. For example, mobile device 110 may have a special update processfor overwriting the FPGA configuration. At 412, mobile device 110determines that the hardware vulnerability no longer exists. Forexample, the mobile device may execute, using processor 302 or thesecond processor (not shown) the vulnerability detection application oranother application that is able to collect state codes to determinewhether the hardware vulnerability has been eliminated.

FIG. 5 illustrates another flow chart 500 for wirelessly updating anFPGA, in accordance with some embodiments of this disclosure. Theactions of FIG. 5 are from the perspective of a server (e.g., server130). Server 130 may include one or more components illustrated in FIG.3 . For example, server 130 may include processor 302, main memory 304,network interface device 320, storage unit 316 and/or other componentsof FIG. 3 .

At 502, server 130 transmits, to mobile device 110, executable codeconfigured to detect a hardware vulnerability. Server 130 may performthe transmission using network interface device 320 via network 326. At504, server 130 receives, from a mobile device, a request for a fix to adetected hardware vulnerability. Server 130 may receive the request vianetwork 326 through network interface device 320. Server 130 may storethe received request in main memory 304 and/or storage unit 316.

At 506, server 130 extracts, from the request, an identifier of aconfiguration update to the FPGA. For example, server 130 may useprocessor 302 to perform the extraction and store the extractedidentifier in main memory 304 and/or storage unit 316. At 508, server130, provides, to a database, a query for the configuration update tothe FPGA, the query including the identifier. Server 130 may retrievethe stored identifier from main memory 304 or from storage unit 316 andgenerate (e.g., using processor 302) a database query for aconfiguration update for the FPGA using the extracted identifier. Thedatabase may reside on server 130 or on a different server. Thus, server130 may pass the query to a database engine that resides on server 130or transmit the query to another server that is hosting the database.

At 510, server 130 receives, from the database, the configuration updateto the FPGA. If the database resides on server 130, server 130 mayreceive the configuration update from the database engine (e.g.,database engine 270) and store the configuration update in main memory304 and/or storage unit 316. If the database resides on another server,server 130 may receive the configuration update using network interfacedevice 320 via network 326. Server 130 may store the receivedconfiguration update in main memory 304 and/or storage unit 316.

At 512, server 130 transmits, to the mobile device, a response to therequest, the response including the configuration update to the FPGA.For example, server 130 may transmit the response using networkinterface device 320 over network 326. At 514, server 130 receives, fromthe mobile device, a confirmation that the hardware vulnerability hasbeen fixed. Server 130 may receive the confirmation using networkinterface device 320 via network 326.

Additional Configuration Considerations

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Certain embodiments are described herein as including logic or a numberof components, modules, or mechanisms. Modules may constitute eithersoftware modules (e.g., code embodied on a machine-readable medium or ina transmission signal) or hardware modules. A hardware module istangible unit capable of performing certain operations and may beconfigured or arranged in a certain manner. In example embodiments, oneor more computer systems (e.g., a standalone, client or server computersystem) or one or more hardware modules of a computer system (e.g., aprocessor or a group of processors) may be configured by software (e.g.,an application or application portion) as a hardware module thatoperates to perform certain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) may bedriven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. As used herein,“hardware-implemented module” refers to a hardware module. Consideringembodiments in which hardware modules are temporarily configured (e.g.,programmed), each of the hardware modules need not be configured orinstantiated at any one instance in time. For example, where thehardware modules comprise a general-purpose processor configured usingsoftware, the general-purpose processor may be configured as respectivedifferent hardware modules at different times. Software may accordinglyconfigure a processor, for example, to constitute a particular hardwaremodule at one instance of time and to constitute a different hardwaremodule at a different instance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods described herein may be at least partiallyprocessor-implemented. For example, at least some of the operations of amethod may be performed by one or processors or processor-implementedhardware modules. The performance of certain of the operations may bedistributed among the one or more processors, not only residing within asingle machine, but deployed across a number of machines. In someexample embodiments, the processor or processors may be located in asingle location (e.g., within a home environment, an office environmentor as a server farm), while in other embodiments the processors may bedistributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a“software as a service” (SaaS). For example, at least some of theoperations may be performed by a group of computers (as examples ofmachines including processors), these operations being accessible via anetwork (e.g., the Internet) and via one or more appropriate interfaces(e.g., application program interfaces (APIs)).

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location (e.g., within a homeenvironment, an office environment, or a server farm). In other exampleembodiments, the one or more processors or processor-implemented modulesmay be distributed across a number of geographic locations.

Some portions of this specification are presented in terms of algorithmsor symbolic representations of operations on data stored as bits orbinary digital signals within a machine memory (e.g., a computermemory). These algorithms or symbolic representations are examples oftechniques used by those of ordinary skill in the data processing artsto convey the substance of their work to others skilled in the art. Asused herein, an “algorithm” is a self-consistent sequence of operationsor similar processing leading to a desired result. In this context,algorithms and operations involve physical manipulation of physicalquantities. Typically, but not necessarily, such quantities may take theform of electrical, magnetic, or optical signals capable of beingstored, accessed, transferred, combined, compared, or otherwisemanipulated by a machine. It is convenient at times, principally forreasons of common usage, to refer to such signals using words such as“data,” “content,” “bits,” “values,” “elements,” “symbols,”“characters,” “terms,” “numbers,” “numerals,” or the like. These words,however, are merely convenient labels and are to be associated withappropriate physical quantities.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. It should be understood thatthese terms are not intended as synonyms for each other. For example,some embodiments may be described using the term “connected” to indicatethat two or more elements are in direct physical or electrical contactwith each other. In another example, some embodiments may be describedusing the term “coupled” to indicate that two or more elements are indirect physical or electrical contact. The term “coupled,” however, mayalso mean that two or more elements are not in direct contact with eachother, but yet still co-operate or interact with each other. Theembodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the invention. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for preventing recording of security sensitivemedia content when that content is displayed on a screen through thedisclosed principles herein. Thus, while particular embodiments andapplications have been illustrated and described, it is to be understoodthat the disclosed embodiments are not limited to the preciseconstruction and components disclosed herein. Various modifications,changes and variations, which will be apparent to those skilled in theart, may be made in the arrangement, operation and details of the methodand apparatus disclosed herein without departing from the spirit andscope defined in the appended claims.

What is claimed is:
 1. A method for wirelessly updatingfield-programmable gate arrays, the method comprising: detecting ahardware vulnerability in a mobile device, wherein the mobile devicecomprises a field-programmable gate array (“FPGA”); in response todetecting the hardware vulnerability in the mobile device, identifying afix for the hardware vulnerability, wherein the fix comprises aconfiguration update to the FPGA; transmitting, to a server, a requestfor the fix to the hardware vulnerability, wherein the request comprisesan identifier of the configuration update to the FPGA; receiving, fromthe server, the configuration update to the FPGA; overwriting a currentFPGA configuration with data from the configuration update; anddetermining that the hardware vulnerability no longer exists.
 2. Themethod of claim 1, wherein detecting the hardware vulnerability in themobile device comprises: retrieving a plurality of state codes for aplurality of hardware devices comprising the mobile device; comparingeach state code of the plurality of state codes to state codes in a listof state codes, wherein one or more state code in the list of statecodes have a corresponding hardware vulnerability; in response todetermining, based on comparing each state code of the plurality ofstate codes, that a state code of the plurality of state codes matches astate code in the list of state codes, detecting the hardwarevulnerability associated with the matching state code.
 3. The method ofclaim 2, wherein identifying the fix for the hardware vulnerabilitycomprises: retrieving a hardware vulnerability identifier associatedwith the matching state code; comparing the hardware vulnerabilityidentifier with each hardware vulnerability identifier in a list ofhardware vulnerability identifiers, wherein one or more hardwarevulnerability identifiers in the list of hardware vulnerabilityidentifiers has a corresponding configuration update to the FPGA; inresponse to determining, based on comparing the hardware vulnerabilityidentifier with each hardware vulnerability identifier in a list ofhardware vulnerability identifiers, that the hardware vulnerabilityidentifier matches a hardware vulnerability identifier in the list,storing the matching hardware vulnerability identifier.
 4. The method ofclaim 3, wherein transmitting, to the server, the request for the fix tothe hardware vulnerability comprises transmitting to the server thematching hardware vulnerability identifier.
 5. The method of claim 1,wherein detecting the hardware vulnerability in the mobile devicecomprises: receiving, from the server, executable code configured todetect the hardware vulnerability; executing the executable code,wherein one or more hardware devices of the plurality of hardwaredevices generate the plurality of state codes in response to executionof the executable code.
 6. The method of claim 5, wherein determiningthat the hardware vulnerability no longer exists comprises: re-executingthe executable code; retrieving one or more new state codes generated inresponse to re-execution of the executable code; and determining, basedon the one or more new state codes, whether the vulnerability no longerexists.
 7. The method of claim 6, wherein re-executing the executablecode comprises re-executing the executable code using the FPGA with theconfiguration update.
 8. A non-transitory computer-readable mediumcomprising memory with instructions encoded thereon for wirelesslyupdating field-programmable gate arrays, causing one or more processorsto perform operations when executed, the instructions comprisinginstructions to: detect a hardware vulnerability in a mobile device,wherein the mobile device comprises a field-programmable gate array(“FPGA”); in response to detecting the hardware vulnerability in themobile device, identifying a fix for the hardware vulnerability, whereinthe fix comprises a configuration update to the FPGA; transmit, to aserver, a request for the fix to the hardware vulnerability, wherein therequest comprises an identifier of the configuration update to the FPGA;receive, from the server, the configuration update to the FPGA;overwrite a current FPGA configuration with data from the configurationupdate; and determine that the hardware vulnerability no longer exists.9. The non-transitory computer-readable medium of claim 8, wherein theinstructions to detect the hardware vulnerability in the mobile devicefurther comprise instructions to: retrieve a plurality of state codesfor a plurality of hardware devices comprising the mobile device;compare each state code of the plurality of state codes to state codesin a list of state codes, wherein one or more state code in the list ofstate codes have a corresponding hardware vulnerability; in response todetermining, based on comparing each state code of the plurality ofstate codes, that a state code of the plurality of state codes matches astate code in the list of state codes, detect the hardware vulnerabilityassociated with the matching state code.
 10. The non-transitorycomputer-readable medium of claim 9, wherein the instructions toidentify the fix for the hardware vulnerability comprise instructionsto: retrieve a hardware vulnerability identifier associated with thematching state code; compare the hardware vulnerability identifier witheach hardware vulnerability identifier in a list of hardwarevulnerability identifiers, wherein one or more hardware vulnerabilityidentifiers in the list of hardware vulnerability identifiers has acorresponding configuration update to the FPGA; in response todetermining, based on comparing the hardware vulnerability identifierwith each hardware vulnerability identifier in a list of hardwarevulnerability identifiers, that the hardware vulnerability identifiermatches a hardware vulnerability identifier in the list, store thematching hardware vulnerability identifier.
 11. The non-transitorycomputer-readable medium of claim 10, wherein the instructions totransmit, to the server, the request for the fix to the hardwarevulnerability comprise instructions to transmit to the server thematching hardware vulnerability identifier.
 12. The non-transitorycomputer-readable medium of claim 8, wherein the instructions to detectthe hardware vulnerability in the mobile device comprise instructionsto: receive, from the server, executable code configured to detect thehardware vulnerability; execute the executable code, wherein one or morehardware devices of the plurality of hardware devices generate theplurality of state codes in response to execution of the executablecode.
 13. The non-transitory computer-readable medium of claim 12,wherein the instructions to determine that the hardware vulnerability nolonger exists comprise instructions to: re-execute the executable code;retrieve one or more new state codes generated in response tore-execution of the executable code; and determine, based on the one ormore new state codes, whether the vulnerability no longer exists. 14.The non-transitory computer-readable medium of claim 13, wherein theinstructions to re-execute the executable code comprise instructions tore-execute the executable code using the FPGA with the configurationupdate.
 15. A system for wirelessly updating field-programmable gatearrays, the system comprising: memory with instructions encoded thereon;and one or more processors that, when executing the instructions, arecaused to perform operations comprising: detecting a hardwarevulnerability in a mobile device, wherein the mobile device comprises afield-programmable gate array (“FPGA”); in response to detecting thehardware vulnerability in the mobile device, identifying a fix for thehardware vulnerability, wherein the fix comprises a configuration updateto the FPGA; transmitting, to a server, a request for the fix to thehardware vulnerability, wherein the request comprises an identifier ofthe configuration update to the FPGA; receiving, from the server, theconfiguration update to the FPGA; overwriting a current FPGAconfiguration with data from the configuration update; and determiningthat the hardware vulnerability no longer exists.
 16. The system ofclaim 15, wherein the operations for detecting the hardwarevulnerability in the mobile device further comprise operations for:retrieving a plurality of state codes for a plurality of hardwaredevices comprising the mobile device; comparing each state code of theplurality of state codes to state codes in a list of state codes,wherein one or more state code in the list of state codes have acorresponding hardware vulnerability; in response to determining, basedon comparing each state code of the plurality of state codes, that astate code of the plurality of state codes matches a state code in thelist of state codes, detecting the hardware vulnerability associatedwith the matching state code.
 17. The system of claim 16, wherein theoperations for identifying the fix for the hardware vulnerabilitycomprise operations for: retrieving a hardware vulnerability identifierassociated with the matching state code; comparing the hardwarevulnerability identifier with each hardware vulnerability identifier ina list of hardware vulnerability identifiers, wherein one or morehardware vulnerability identifiers in the list of hardware vulnerabilityidentifiers has a corresponding configuration update to the FPGA; inresponse to determining, based on comparing the hardware vulnerabilityidentifier with each hardware vulnerability identifier in a list ofhardware vulnerability identifiers, that the hardware vulnerabilityidentifier matches a hardware vulnerability identifier in the list,storing the matching hardware vulnerability identifier.
 18. The systemof claim 17, wherein the operations for transmitting, to the server, therequest for the fix to the hardware vulnerability comprise operationsfor transmitting to the server the matching hardware vulnerabilityidentifier.
 19. The system of claim 15, wherein the operations fordetecting the hardware vulnerability in the mobile device compriseoperations for: receiving, from the server, executable code configuredto detect the hardware vulnerability; executing the executable code,wherein one or more hardware devices of the plurality of hardwaredevices generate the plurality of state codes in response to executionof the executable code.
 20. The system of claim 15, wherein theoperations for determining that the hardware vulnerability no longerexists comprise operations for: re-executing the executable code;retrieving one or more new state codes generated in response tore-execution of the executable code; and determining, based on the oneor more new state codes, whether the vulnerability no longer exists.